rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables #68881
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
bors
added a commit
that referenced
this pull request
Feb 6, 2020
rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated). Also see #8855 (comment). I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway. r? @michaelwoerister or @nagisa cc @rkruppe @nikomatsakis
|
☀️ Try build successful - checks-azure |
|
Queued aa7e872 with parent 333c32a, future comparison URL. |
|
r=me given no major perf regressions. Doubt there will be any tho. |
|
Does this have much impact on the actual optimized codegen with/without debuginfo? IMO, the ideal is that debuginfo has zero effect on codegen, just makes a best effort to track and describe it after the fact. |
|
Finished benchmarking try commit aa7e872, comparison URL. |
|
@cuviper This only affects DWARF output, not codegen. Also note that the wrong code set it to |
|
Sounds good, thanks! |
|
@bors r=nagisa |
|
📌 Commit b82f6c5 has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Feb 8, 2020
…agisa rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated). Also see rust-lang#8855 (comment). I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway. r? @michaelwoerister or @nagisa cc @rkruppe @nikomatsakis
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Feb 8, 2020
…agisa rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated). Also see rust-lang#8855 (comment). I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway. r? @michaelwoerister or @nagisa cc @rkruppe @nikomatsakis
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Feb 9, 2020
…agisa rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated). Also see rust-lang#8855 (comment). I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway. r? @michaelwoerister or @nagisa cc @rkruppe @nikomatsakis
bors
added a commit
that referenced
this pull request
Feb 9, 2020
Rollup of 5 pull requests Successful merges: - #68738 (Derive Clone + Eq for std::string::FromUtf8Error) - #68742 (implement AsMut<str> for String) - #68881 (rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables) - #68911 (Speed up the inherent impl overlap check) - #68913 (Pretty-print generic params and where clauses on associated types) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a
boolargument, but there it means something unrelated).Also see #8855 (comment).
I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to
truewhen LLVM could optimize them away, so this PR should have no effect anyway.r? @michaelwoerister or @nagisa cc @hanna-kruppe @nikomatsakis